本篇是最後五天方法回顧的第三篇。

本篇要回答：有了證據之後，怎麼把它們組織成一條能支撐結論的軌跡，而不是一堆按時間排序的 log？

五個故事，五條軌跡

回看各故事的「重現」篇，做的其實是同一件事：

• 故事一：需求 → 提問 → 決策——斷在第一節點，預期結果從未被寫下。
• 故事二：執行入口 → interpreter 解析 → 套件集合 → 測試結果——在第二節點分岔成兩條。
• 故事三：賦值 → 函式傳遞 → 轉換 → 序列化邊界——變形發生在第一節點，引爆在最後。
• 故事四：原始碼 → lint 改寫 → ORM expression → SQL → 查詢結果——語意在中段被偷換。
• 故事五：發布 → 送達 → 受理 → 執行 → 外部效果——介面試圖在第一節點預支最後一格。

五案的失效位置各不相同，但軌跡模板是同一條：

主張或需求提出
        ↓
輸入被接受
        ↓
程式、工具或服務開始處理
        ↓
資料或狀態發生轉換
        ↓
外部元件接受或拒絕
        ↓
執行完成或失敗
        ↓
狀態回報
        ↓
使用者真正需要的結果發生

每一個節點要回答的問題

軌跡不是畫出來就算數，每個節點要能通過六連問：由誰負責？有什麼直接證據？目前只是推論嗎？是否有一致的識別碼與時間？失敗、逾時與重試如何呈現？是否存在完全不可觀測的斷點？

第六問最關鍵。故事二的斷點是「IDE 用哪個 interpreter」沒有任何輸出可查；故事四的斷點是「工具改寫了什麼」沒有 diff 留存；故事五的斷點是「設備執行了沒有」沒有回路。事故最喜歡住在不可觀測的節點裡——調查畫軌跡的過程，經常同時是第一次發現「原來這一段是黑的」。

軌跡與 log 的差別

把 log 按時間排序，得到的是「事情的順序」；事件軌跡要求的是「狀態的因果」——每一個狀態都要能回答：我是從哪個前置狀態、憑什麼證據推進過來的。順序自己不構成因果：兩筆相鄰的 log 可能屬於兩條不相干的請求（所以需要貫穿 ID），也可能中間隔著一個沒有留下任何紀錄的黑箱（所以需要第六問）。

本篇結論

事故軌跡不是把 Log 排成時間順序，而是證明每一個狀態如何從前一個狀態成立。

下一篇（Day 29）處理軌跡終點的誘惑：找到出錯的那一行之後，先別急著結案——直接原因、促成因素與系統性缺口要分開算帳。